package com.springboot.controller;



import com.springboot.entity.Employee;
import com.springboot.util.JsonResult;
import org.springframework.web.bind.annotation.PathVariable;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RequestMethod;
import org.springframework.web.bind.annotation.ResponseBody;

import java.util.Arrays;
import java.util.List;

        /**
         * 在使用Restful风格前的控制器写法
         */
        /* API（Application Programming Interface，应用程序接口）是一些预先定义的函数，
            或指软件系统不同组成部分衔接的约定。目的是提供应用程序与开发人员基于某软件或硬件得以访问一组例程的能力，
            而又无需访问原码，或理解内部工作机制的细节。*/

        /*
            实际上的简单理解：两种用法：
            1>类似jar的使用，A软件将功能打包成组件(功能块:比如java中jar)，让B软件导入直接使用（就是导包或者导依赖）
            2>http请求方式：A项目(系统)提供一个映射方法路径，B项目(系统)发起http请求得到对应功能
                    (项目对外提供一个映射路径，别人访问该路径可以得到对应的东西)(应用请求方式)(这种就是API开发)
        */

        /*
            应用接口:  很多情况下,需要把系统的功能作为服务暴露给外部的其他应用使用,就需要把系统中的服务作为API接口暴露出去,
            一般分为公共接口(发短信,天气服务)和私用接口(公司内部使用的);
        */
/*@Controller*/
public class EmployeeController {
    /*需求：查询所有员工
     * 1>请求路径:/employees
     * 2>请求方式:GET
     * 3>请求参数:无
     * 4>请求返回值:list<Employee> json格式
     * */
    @RequestMapping(value = "/employees", method = RequestMethod.GET)
    @ResponseBody
    public List<Employee> list() {
        return Arrays.asList(new Employee(1L, "dafei", 18), new Employee(2L, "xiaoofei", 18));
    }
    /*需求：查询id=1的员工
     * 1>请求路径:/employees
     * 2>请求方式:GET
     * 3>请求参数:id
     * 4>请求返回值:Employee json格式
     * */
    //员工列表查询与员工单个查询，使用了相同的映射路径：/employees和相同的1请求方法RequestMethod.GET
    //导致请求路径（路径+请求方法）一样，报错，怎么办?
    //restful提供解决方案:使用参数路径方式
    //参数路径:将参数作为请求路径的一部分
    //比如:/employees/{id}  此处{id}就是一个参数，但是这样又没法获得id值，所以还得再配合一个注解@PathVariable

    //浏览器或postman发起请求时使用：http://localhost:8080/employees/22 其中的22就是id参数值，同时也是请求路径的一部分
    //另外，请求映射方法必须使用@PathVariable 进行参数继续
    //注意：如果路径参数标记与请求映射方法参数名不一致时怎么办?会报500错
    //可以使用@PathVariable（"eid"）value属性来指定
    /*    @RequestMapping(value = "/employees", method = RequestMethod.GET)*/
    /*修改为：*/
    @RequestMapping(value = "/employees/{id}", method = RequestMethod.GET)
    @ResponseBody
    public Employee detail(@PathVariable Long id) {
        return new Employee(id, "dafei", 18);
    }

    /*需求：员工添加
     * 1>请求路径:/employees
     * 2>请求方式:POST
     * 3>请求参数:employee(name,age)
     * 4>请求返回值:添加成功员工对象
     * */
    @RequestMapping(value = "/employees", method = RequestMethod.POST)
    //路径可以一样，但是方法不能一样，所以都能/employees，但后面的必须不一样
    @ResponseBody
    public Employee save(Employee employee) {
        employee.setId(1L);
        return employee;
    }

    @RequestMapping(value = "/employees", method = RequestMethod.PUT)
    //路径可以一样，但是方法不能一样，所以都能/employees，但后面的必须不一样
    @ResponseBody
    public Employee update(Employee employee) {
        employee.setName("asd");
        return employee;
    }

    /*需求：员工删除
     * 1>请求路径:/employees
     * 2>请求方式:DELETE
     * 3>请求参数:id
     * 4>请求返回值:
     * */
    @RequestMapping(value = "/employees", method = RequestMethod.DELETE)
//路径可以一样，但是方法不能一样，所以都能/employees，但后面的必须不一样
    @ResponseBody
    public JsonResult delete(Long id) {
        return JsonResult.success();//这个success是里面写的方法，返回一个空参对象，空参默认success成功
    }


}


/*
#### 传统的开发模式与前后端分离模式对比

**传统的开发模式**

前端写好静态的html页面交给后端开发，后端把html改成模板，然后使用模板引擎去套模板，比如jsp，freemarker等
后端人员在开发过程中如果发现页面有问题，要返回给前端修改，前端再交给后端，直至功能实现。

问题：前后端严重耦合
1.前端需要改bug调试时，需要在当前电脑安装一整套后端的开发工具，启动后端程序。
2.还要求后端人员会html，js等前端语言。
3.前端页面也会嵌入很多后端的代码
4.一旦后端换了一套语言，前端也需要重新开发
5.沟通成本，调试成本，前后端开发进度相互影响，从而大大降低开发效率




**前后端分离**

前后端分离并不只是开发模式，也是web应用的一种架构模式。
在开发阶段，前后端人员约定好数据交互接口，即可并行开发与测试。

前端开发完成可以独自进行mock测试，后端也可以使用postman等接口测试工具进行测试。
最后可进行功能联调测试。

优点：
1.前后端责任清晰，后端专注于数据上，前端专注于视觉上。
2.无需等待对方的开发工作结束，提高开发效率。
3.可应对复杂多变的前端需求。
4.增强代码可维护性

**特别的返回值-根据需求决定**

GET /collection：返回资源对象的列表（数组）
GET /collection/resource：返回单个资源对象
POST /collection：返回新生成的资源对象
PUT /collection/resource：返回完整的资源对象
PATCH /collection/resource：返回完整的资源对象
DELETE /collection/resource：返回一个空文档

**Accept与Content-Type的区别**

Accept：application/json，代表客户端希望接收的数据类型，只能是发请求的时候带的

Content-Type：application/json，代表客户端/服务器，携带的数据的类型

**参数路径方式与传统方式对比：**

参数路径方式优缺点

优点:可以隐藏参数，避免暴露参数，相对安全

缺点：如果参数较多url路径很长，**不建议使用**

拓展(设计接口):
1>员工登录/注册接口  /employees/login  /regist  post
2>某个员工1月份工资  /employees/{id}/salary/{month}    get
3>员工所有工资记录   /employees/salary     get
 */